-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
added --no-run option for rustdoc #83857
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @CraftSpider (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
This comment has been minimized.
This comment has been minimized.
src/librustdoc/config.rs
Outdated
@@ -121,6 +121,8 @@ crate struct Options { | |||
/// For example, using ignore-foo to ignore running the doctest on any target that | |||
/// contains "foo" as a substring | |||
crate enable_per_target_ignores: bool, | |||
/// Compile test but do not run them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we could tell others that this is the opposite of should_test
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not the opposite, they do different things (and no_run
requires should_test
to also be set).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me (but not sure if it's working).
This comment has been minimized.
This comment has been minimized.
test $DIR/no-run-flag.rs - f (line 11) ... ok | ||
test $DIR/no-run-flag.rs - f (line 14) ... ignored | ||
test $DIR/no-run-flag.rs - f (line 17) ... ok | ||
test $DIR/no-run-flag.rs - f (line 23) ... ok | ||
test $DIR/no-run-flag.rs - f (line 28) ... ok | ||
test $DIR/no-run-flag.rs - f (line 32) ... ok | ||
test $DIR/no-run-flag.rs - f (line 8) ... ok |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it didn't run why is it "ok"? IIRC that is the same as test passing right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so adding the --no-run
flag change the behavior of the test like it was annotated as ```no_run. Maybe this is unwanted and something else should be displayed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ping @CraftSpider @jyn514 should we have a different text? "ok" may be confusing since it didn't run. Also note that we may also want a different color or the same color as "ignored".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm. I don't think 'ignored' is quite right, but 'ok' is also a bit confusing. If we can make it something new, maybe something like 'built' or 'checked'? If not, I think 'ok' is more accurate than 'ignored'.
Color-wise, I'm fine with it being ok colored, as it is a requested change to behavior, not implicit, so it's requested to treat it as success. If that makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After investigations I think that in order to do so, I have to modify the lib test. This will also affect all tests and not just doctests. Do you think this is a worthwhile investment and should this be in a different PR ? Anyway I would be interested in implementing that but the scope is a bit bigger than I anticipated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no_run
by itself is useless.
To summarize:
- if you run
rustdoc -Z unstable-options --no-run
it just build the documentation, it has the same behavior as justrustdoc
rustdoc -Z unstable-options --no-run --test
run the doctest set. It behave as if every test had the no_run meaning they won't run. Meaning that test like
```
panic!()
```
will print as ok like
```no_run
panic!()
```
without the--no-run
flag
I agree that is confusing. Maybe a error should be raised if no_run is active and not should_test
. However I think that if you run rustdoc -Z unstable-options --no-run
your intention was probably to run the test instead of documenting your project.
I assume that in the original issue the final goal would be to be able to generate bin (with --persist-doctests
) but without running them.
Or maybe a another possible case would be to unify the behavior of cargo test --no-run
(provided that down the line cargo is also modified). For instance cargo test --all
test both regular test and doctest but cargo test --all --no-run
skips doctest cargo test --doc --no-run
give an error.
Now if the explicit goal is to harmonize with regular test the output should just be empty.
Another option would for me to change the test lib such that no_run test display something like test foo ... checked
, provided that such change is desirable (to discuss thought the RFC process ?).
Moreover test with compile_fail
should also print something different maybe checked is also desirable.
I am new contributing for rust so I am not quite sure of what to do to solve this issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that is confusing. Maybe a error should be raised if no_run is active and not should_test. However I think that if you run rustdoc -Z unstable-options --no-run your intention was probably to run the test instead of documenting your project.
I think we should give a hard error here; if people meant to run the test they can add --test
. Could you suggest adding --test
in the error message?
See
Lines 587 to 593 in 202659a
} else if !out_fmt.is_json() && show_coverage { | |
diag.struct_err( | |
"html output format isn't supported for the --show-coverage option", | |
) | |
.emit(); | |
return Err(1); | |
} |
I think all your other changes can go in a follow-up PR, I don't think we should be changing libtest here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok thank you. I have not change libtest yet I will work on that too :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please do not change libtest in this pr. I am not a maintainer and don't know who to ask to approve; finding out will delay landing this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I was not clear. I will do another PR for libtest
Ping from triage: |
At this moment it is unclear for me what is wanted. Could someone clarify this please ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, just a couple nits :) r=me with those addressed.
Co-authored-by: Joshua Nelson <[email protected]>
@bors r+ |
📌 Commit 03c710b has been approved by |
☀️ Test successful - checks-actions |
Show test type during prints Test output can sometimes be confusing. For example doctest with the no_run argument are displayed the same way than test that are run. During rust-lang#83857 I got the feedback that test output can be confusing. For the moment test output is ``` test $DIR/test-type.rs - f (line 12) ... ignored test $DIR/test-type.rs - f (line 15) ... ok test $DIR/test-type.rs - f (line 21) ... ok test $DIR/test-type.rs - f (line 6) ... ok ``` I propose to change output by indicating the test type as ``` test $DIR/test-type.rs - f (line 12) ... ignored test $DIR/test-type.rs - f (line 15) - compile ... ok test $DIR/test-type.rs - f (line 21) - compile fail ... ok test $DIR/test-type.rs - f (line 6) ... ok ``` by indicating the test type after the test name (and in the case of doctest after the function name and line) and before the "...". ------------ Note: this is a proof of concept, the implementation is probably not optimal as the properties added in `TestDesc` are only use in the display and does not represent actual change of behavior, maybe `TestType::DocTest` could have fields
Show test type during prints Test output can sometimes be confusing. For example doctest with the no_run argument are displayed the same way than test that are run. During rust-lang#83857 I got the feedback that test output can be confusing. For the moment test output is ``` test $DIR/test-type.rs - f (line 12) ... ignored test $DIR/test-type.rs - f (line 15) ... ok test $DIR/test-type.rs - f (line 21) ... ok test $DIR/test-type.rs - f (line 6) ... ok ``` I propose to change output by indicating the test type as ``` test $DIR/test-type.rs - f (line 12) ... ignored test $DIR/test-type.rs - f (line 15) - compile ... ok test $DIR/test-type.rs - f (line 21) - compile fail ... ok test $DIR/test-type.rs - f (line 6) ... ok ``` by indicating the test type after the test name (and in the case of doctest after the function name and line) and before the "...". ------------ Note: this is a proof of concept, the implementation is probably not optimal as the properties added in `TestDesc` are only use in the display and does not represent actual change of behavior, maybe `TestType::DocTest` could have fields
Show test type during prints Test output can sometimes be confusing. For example doctest with the no_run argument are displayed the same way than test that are run. During rust-lang#83857 I got the feedback that test output can be confusing. For the moment test output is ``` test $DIR/test-type.rs - f (line 12) ... ignored test $DIR/test-type.rs - f (line 15) ... ok test $DIR/test-type.rs - f (line 21) ... ok test $DIR/test-type.rs - f (line 6) ... ok ``` I propose to change output by indicating the test type as ``` test $DIR/test-type.rs - f (line 12) ... ignored test $DIR/test-type.rs - f (line 15) - compile ... ok test $DIR/test-type.rs - f (line 21) - compile fail ... ok test $DIR/test-type.rs - f (line 6) ... ok ``` by indicating the test type after the test name (and in the case of doctest after the function name and line) and before the "...". ------------ Note: this is a proof of concept, the implementation is probably not optimal as the properties added in `TestDesc` are only use in the display and does not represent actual change of behavior, maybe `TestType::DocTest` could have fields
resolve #59053
add
--no-run
option forrustdoc
for compiling doc test but not running them.Intended for use with
--persist-doctests
.